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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalization ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in 
the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television 
services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters 
market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the 
broadcast industry. 

The present document is part 1 of a multi-part deliverable covering the Digital Video Broadcasting (DVB); IP Datacast: 
Program Specific Information (PSI)/Service Information (SI) as identified below: 

Part 1: "IP Datacast over DVB-H "; 

Part 2: "IP Datacast over DVB-SH". 



Introduction 

The present document describes the usage of PSI/SI information in IPDC in DVB-H System. The document 

intentionally constrains PSI/SI to simplify requirements for equipments developed for IPDC in DVB-H Systems. 

TS 102 470-2 [i.3] is a corresponding document describing usage of PSI/SI information in IPDC in DVB-SH systems. 

Intended readers of the present document are those implementing or operating IPDC in DVB-H Networks as well as 
those implementing receivers for such networks. The reader is assumed being familiar with MPEG/DVB defined PSI/SI 
information. 

The aim of the present document is to define the way PSI/SI information is used in IPDC in DVB-H Systems. An 
operator of an IPDC in DVB-H Network should understand what information should be available, and a receiver vendor 
should understand how the information is available. 
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The contents of the present document are normative for IPDC DVB-H Networks and IPDC DVB-H Receivers, unless 
otherwise stated. 
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1 Scope 

The present document describes PSI/SI tables and descriptors usage in DVB-H system. 

Tables and descriptors are introduced, and their usage is described. 

The present document defines the set of PSI/SI data an IPDC DVB-H Receiver may expect to be available on an IPDC 
DVB-H Bearer (data transmission baseband) and the IPDC DVB-H Network is expected to make available on the IPDC 
DVB-H Bearer. 

The scope of the present document is to support coherent and interoperable signalling on data link layer on all IPDC 
DVB-H Networks 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[I] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated 

audio information: Systems". 

[2] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[3] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". 

[4] IETF RFC 1112: "Host extensions for IP multicasting". 

[5] IETF RFC 2464: "Transmission of IPv6 Packets over Ethernet Network". 

[6] ETSI EN 302 304: "Digital Video Broadcasting (DVB); Transmission System for Handheld 

Terminals (DVB-H)". 

[7] ETSI TS 102 006: "Digital Video Broadcasting (DVB); Specification for System Software Update 

in DVB Systems". 
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2.2 Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 101 211: "Digital Video Broadcasting (DVB); Guidelines on implementation and usage 

of Service Information (SI)". 

[i.2] ETSI ETR 162: "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes 

for DVB systems". 

[i.3] ETSI TS 102 470-2: "Digital Video Broadcasting (DVB); IP Datacast: Program Specific 

Information (PSI)/Service Information (SI); Part 2: IP Datacast over DVB-SH". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 
delivery system: physical medium by which one or more multiplexes are transmitted 

NOTE: E.g. satellite system, wide-band coaxial cable, fibre optics, terrestrial channel of one emitting point. 
DVB-H: transmission system targeted to provide IP-based services to handheld terminals over terrestrial radio channels 

NOTE: As defined in EN 302 304 [6]. 

DVB network: collection of MPEG-2 Transport Streams, each carried in a multiplex, and transmitted on a single 
delivery system 

NOTE: DVB network is identified by network_id. 
DVB service: collection of associated Elementary Streams 

NOTE: DVB service is identified by program_number (in PSI), or service_id (in SI). 

DVB signal: radio signal carrying a Transport Stream of a DVB network 

elementary stream: Stream of Transport packets within a Transport Stream sharing a common Packet IDentified (PID) 

INT notification NIT/BAT: NIT or BAT sub_table containing a linkage_descriptor with linkage_type OxOC 

IP datacast baseline: minimum core protocol profile an IPDC DVB-H Receiver may expect to be available on IPDC 
DVB-H Bearer (data transmission baseband) and the IPDC DVB-H Network is expected to make available on the IPDC 
DVB-H Bearer 

IP flow: flow of IP datagrams each sharing the same IP source and destination address 

NOTE: An IP flow is identified within an IP platform by its source and destination addresses. IP flows on 

different IP platforms may have the same source/destination addresses, but are considered different IP 
flows. IP flows may be delivered over one or more IP streams. 

IPDC DVB-H bearer: link and physical layers into which IP platform is encapsulated 

IPDC DVB-H network: DVB network that makes the IP Datacast based services and the IP Datacast Baseline 
available over DVB-H for an IPDC Datacast Receiver 

IPDC DVB-H receiver: equipment or system that acquires IP Datacast based services provided over the IP Datacast 
Baseline on DVB-H 

IPDC in DVB-H system: consists of one or more IPDC DVB-H Networks and one or more IPDC DVB-H Receivers 
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IP/MAC notification info structure: structure in data_broadcast_id_descriptor when data_broadcast_id is set to OxOB 

IP/MAC notification service: DVB service with a component carrying one or more INT sub_tables 

IP/MAC notification service structure: structure in linkage_descriptor when linkage_type is set to OxOB 

IP platform: set of IP flows managed by an organization 

NOTE: The IP platform represents a harmonized IP address space that has no address collisions. An IP platform 
may span several Transport Streams within one or more DVB networks. Several IP platforms may 
co-exist in the same Transport Stream. IP platform is identified by platform_id. 

IP stream: physical mapping of an IP Flow to transport_stream_id, original_network_id, service_id, component_tag, 
and IP source/destination addresses 

NOTE: IP stream is delivered on an MPE section stream. 

multiplex: stream of all the digital data carrying one or more services within a single physical channel (characterized 
by parameters like carrier frequency and modulation modes) 

MPE-FEC section: As specified in EN 301 192 [3]. 

MPE section: datagram_section 

NOTE: As specified in EN 301 192 [3]. 

MPE section stream: stream of MPE sections each sharing the same MAC-address and delivered within a particular 
Elementary Stream 

NOTE: Within an Elementary Stream, MPE section stream is identified by its MAC address. 

multiprotocol encapsulation info structure: structure in data_broadcast_descriptor and data_broadcast_id_descriptor 
when data_broadcast_id is set to OxOB 

NIT_actual: NIT sub_table describing the actual delivery network. NIT_actual has table_id value 0x40 

section: syntactic structure 

NOTE: As defined in ISO/IEC 13818-1 [1]. 
transport stream: stream of transport_packets 

NOTE: As defined in ISO/IEC 13818-1 [1]. 
transport (stream) packet: data structure 

NOTE: As defined in ISO/IEC 13818-1 [1]. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ATSC Advanced Television Systems Committee 

BAT Bouquet Association Table 

CA Conditional Access 

CAT Conditional Access Table 

DVB Digital Video Broadcasting 

EIT Event Information Table 

ES Elementary Stream 

FEC Forward Error Correction 

INT IP/MAC Notification Table 

IP Internet Protocol 

IPDC IP DataCast 

IPv4 Internet Protocol, version 4 

IPv6 Internet Protocol, version 6 
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LSB Least Significant Bit 

MAC Medium Access Control 

Mbps Mega bits per second 

MPE Multiprotocol Encapsulation 

MPEG Moving Picture Expert Group 

MSB Most Significant Bit 

NIT Network Information Table 

NVOD Near Video On Demand 

OUI Organizationally Unique Identifier 

PAT Program Association Table 

PID Packet IDentifier 

PMT Program Map Table 

PSI Program Specific Information 

QAM Quadrature Amplitude Modulation 

RST Running Status Table 

SDT Service Description Table 

SI Service Information 

ST Stuffing Table 

TDT Time and Data Table 

TOT Time Offset Table 

TPS Transmission Parameter Signalling 

TS Transport Stream 

TSDT Transport Stream Description Table 

UNT Update Notification Table 

UTC Universal Time, Co-ordinated 



4 Introduction to DVB-H and PSI/SI (informative) 

The contents of this clause are informative. 

NOTE: References [1], [2] and [3] are open for different interpretations regarding some of the terminology, in 
particular "multiplex", "Transport Stream" and "network". For the purpose of the present document a 
particular recommended interpretation has been adopted, but it should be noted that other interpretations 
are also possible and may exist in real implementations. It should however be remembered that such 
different interpretations do not affect the logical relationship between the various PSI/SI parameters 
transmitted in PSI/SI tables, which is clear and unambiguous and specified in clause 5. A difference in 
interpretation of terminology should therefore not affect interoperability between network and terminal, 
as long as clause 5 is fulfilled and a receiver only uses this logical relationship to find services and does 
not presume any particular interpretation of terminology. 

Within the current document "multiplex" and "Transport Stream" are considered synonymous, as is also implicitly the 
case in many places of [2] and [3]. Although a transport_stream_id, according to [2] shall uniquely reference a 
Transport Stream, the adopted recommended interpretation within the present document is however that this does not 
imply that a particular transport_stream_id always implies the identical byte stream - the PSI/SI may e.g. be different if 
the TS is transmitted in another network. The uniqueness is interpreted as referring to the content rather than to the byte 
stream. Furthermore, the adopted recommended interpretation for the term "network" does not require a network to 
transmit the same TSs on all emitting sites. 



4.1 



PSI/SI and DVB network 



A DVB network is uniquely identified by a network_id. A DVB network consists of one or more multiplexes/Transport 
Streams (TSs), each being transmitted by one or more DVB signals. All emitting sites of a network do not need to 
transmit all multiplexes/TSs of the network. Information about a DVB network is available within the NIT sub_table 
(identified by network_id). The NIT lists all multiplexes/TSs and DVB signals available within the DVB network. The 
NIT is carried within each DVB network. 
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DVB networks 


DVB networl^ 1 

ID: networl^ id 

PSI/SI: NIT 






^^ 


^^ 






^^^ 


^ 








^^ 


Transport Streams 


Multiplex 1 

ID: trans port_stream_id + 

original network id 

PS I/SI: PAT 




Multiplex 2 

ID: transport_streamJd + 

original network id 

PSI/SI: PAT 




Multiplex 3 

ID: trans port_stream_id + 

original network id 

PSI/SI: PAT 








^^ 


"^^-\ 








^^ 










^\^ 


DVB services 


DVB service 1 
ID: service id 
PSI/SI: PMT 




DVB service 2 
ID: service id 
PSI/SI: PMT 




DVB service 3 
ID: service id 
PSI/SI: PMT 








^^ 


^^ 








^,^ 








" 


^^ 


Elementary Streams 


Component 1 
ID: component_tag, PID 




Component 2 
ID: component_tag, PID 




Component 3 
ID: com pone nt_tag, PID 



Figure 1 : Relation between DVB networks, Transport Streams, DVB services and components 

A multiplex/TS is identified by transport_stream_id and original_network_id. Transport_stream_id is unique within 
original_network_id. A particular multiplex/TS may be transmitted on several different radio signals (i.e. DVB signals) 
within one network. A multiplex/TS could also be transmitted on several DVB networks, in which case the TS byte 
stream of the multiplex/TS may differ between networks. If the DVB signals belong to different DVB networks, the SI 
(particularly the information about the actual DVB network, i.e. content of NIT_actual) of the TS byte stream of a 
particular multiplex/TS will necessarily differ between networks. 

The network_id of the DVB network transmitting the Transport Stream is announced in the NIT_actual carried within 
the Transport Stream. 

A DVB signal using non-hierarchical modulation carries one Transport Stream, while a DVB signal using hierarchical 
modulation carries two Transport Streams. 

Information about a particular multiplex/TS is available within the PAT carried within the multiplex/TS. The PAT lists 
all DVB services available within the multiplex/TS. On each multiplex/TS exactly one PAT is available. 

A DVB service is a sequence of programme events, each of which groups together a set of components, each carried in 
its own Elementary Stream. A DVB service containing no components is a NULL-service, carrying no content. A DVB 
service is globally and uniquely identified by the triplet of (service_id, transport_stream_id, original_network_id). The 
service_id is unique at least within a multiplex. 

All the components of a DVB service (if any) are carried within a single multiplex/TS. Information about a DVB 
service is available within a PMT sub_table (identified by service_id), carried within the same multiplex/TS. 

A component is identified by the component_tag. The component_tag is unique within a DVB service. The component 
is carried within an Elementary Stream (ES), identified by the PID. The PID is unique within a Transport Stream. 
Mapping between component_tag and PID is signalled in PMT. 

It is possible to have one Elementary Stream carrying a component of more than one DVB service, as illustrated in 
figure 2. 
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DVB services 



DVB service 1 
ID: servicejd 
PSI/SI: PMT 



DVB service 2 
ID: servicejd 
PSI/SI: PMT 



Elementary Streams 




Component 1 
ID: componentjag, PID 



Component 2 
ID: oomponent_tag, PID 



Component 1 
ID: oomponentjag, PID 



Figure 2: Two DVB services shiaring a component 



4.2 IP platform, IP flow and IP stream 

An IP platform is a set of IP flows managed by an organization. The IP platform represents a harmonized IP address 
space that has no address collisions. 

An IP platform may be available on multiple Transport Streams, within one or multiple DVB networks. In such case, 
each of the Transport Streams may carry any subset of the IP flows of the IP platform. 

An IP platform is identified by platform_id. Platform_id values are divided into two ranges (see annex D of 
EN 301 192 [3]). One range consists of platform_id values that are globally unique. If such a platform_id value is 
signalled in two different DVB networks, it refers to the same IP platform. The other range consists of platform_id 
values unique only within the scope of a DVB network. Data from an IP platform identified by such platform_id is not 
available in any other DVB network. Such an IP platform is globally and uniquely identified only by combination of 
both platform_id and network_id. 

Each IP platform contains one or more IP flows, each delivered on one or more IP streams. An IP flow is identified 
within an IP platform by its source and destination addresses and port number. IP flows are IP platform specific, and 
two different IP flows on two different IP platforms may use the same source/destination addresses. Each IP flow may 
be delivered over one or more IP streams. 

An IP stream is a data stream delivering exactly one instance of an MPE encoded IP flow. An IP stream is identified by 
transport_stream_id, original_network_id, servicejd, component_tag, and IP source/destination addresses (all 
together): 

• Transport_stream_id and original_network_id together identify a single Transport Stream. 

• Service_id and component_tag together identify a single Elementary Stream within a Transport Stream. Note 
that an Elementary Stream may also be identified by its PID. 

• IP source/destination addresses identify a single IP stream within an Elementary Stream. This is required if 
multiple IP streams are carried within the Elementary Stream. Note that IP streams within an Elementary 
Stream are differentiated by the IP source/destination address only. 

Two different elementary streams, carrying IP streams which contain the same IP flow may be located in different 
multiplexes. In such case, an IPDC DVB-H Receiver may accomplish a handover between these multiplexes while 
receiving the IP flow. 

Note that the INT does not always announce the source address of an IP flow. This is done to optimize the bandwidth 
required by the INT. In such case, IP stream differentiation is based on the destination address only. 

An IP stream is a single data stream delivering an IP flow. An IP stream is identified by associated parameters 
indicating its location (network_id, original_network_id, transport_stream_id, service_id and component_tag). An IP 
flow represents the data content of a stream, while an IP stream represents an instantiation of such an IP flow. An IP 
flow belongs to exactly one IP platform. Note that an IP stream may be announced by multiple INT sub_tables, 
eventually making it part of multiple IP platforms. 
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IP platforms 


IP platform 1 

ID: platform id 

PSI/SI: INT 






^^ 


^-^-^ 






^^^ 










^^ 


IP flow 


IP flow 1 
ID: IP address 




IP flow 2 
ID: IP address 




IP flow 3 
ID: IP address 








.^^ 


^^ 








^^ 










^--^ 


IP streams 


IP stream 1 

ID: transport_stream_id + 

original network id + 

PID 




IP stream 2 

ID: transport_stream_id + 

original network id + 

PID 




IP stream 3 

ID: transport_stream_id + 

original network id + 

PID 



Figure 3: Relation between IP platform, IP flow and IP stream 



4.3 Multiprotocol Encapsulation (MPE) 

DVB has introduced Multiprotocol Encapsulation (MPE) for encoding OSI-model layer 3 (Network Layer) datagrams 
into Transport Stream packets. MPE is defined in EN 301 192 [3]. Each IP datagram is encoded into a single MPE 
section. The IP datagram starts immediately after the MAC_address_l field. The maximum size of an IP datagram 
(including the IP datagram header) is 4 080 bytes. 

Single Elementary Stream may contain multiple MPE section streams. Within an Elementary Stream, MPE section 
stream is identified by its MAC_address field. Note that IPDC DVB-H Receiver may differentiate MPE encoded IP 
streams by checking the IP source and/or destination address in the IP datagram carried within an MPE section. In such 
case the Receiver does not differentiate MPE section streams, but is directly filtering IP streams. For such a Receiver, 
there is no need to differentiate MPE section streams within an Elementary Stream. 

For each Elementary Stream carrying MPE encapsulated IP stream(s), the SDT_actual contains a 
data_broadcast_descriptor. The following applies to this descriptor: 

• The data_broadcast_id field is set to 0x0005, indicating the Multiprotocol Encapsulation Info Structure is used. 

• The selector_length field is set to 2. 

• The max_sections_per_datagram field is set to 1, indicating the maximum number of sections that can be used 
to carry a single datagram unit. 

• The component_tag field is set to the value announced within the PMT sub_table of the DVB service for the 
referred component. 
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Figure 4: Relation between Transport pacltet stream, IVIPE section stream and IP stream 



4.4 



PSI Tables 



Program Specific Information (PSI) consists of data enabling a decoder to demultiplex DVB services. DVB services are 
composed of one or more Elementary Streams, each carried on a PID. DVB services, Elementary Streams or parts 
thereof may be scrambled for conditional access. However, PSI shall not be scrambled. 

In a Transport Stream, the PSI is carried in MPEG-2 private table structures. While these structures may be thought of 
as simple tables, they are segmented into sections and inserted into Transport Stream packets, some with predetermined 
PIDs and others with operator selectable PIDs. 

Following applies to all PSI tables: 

• The section number of the first section of each sub_table is 0x00. 

• The section_number is increment by 1 with each additional section of a sub_table. 

• Any addition, the removal or change in content of any section within a sub_table affects a version number 
change. Two sequential transmissions of a sub_table using the same version_number have the same number of 
sections, and the content and order of sections are identical. 



4.4.1 Program Association Table (PAT) 



Program Association Table (PAT) provides the correspondence between a program_number and the PID value of the 
Transport Stream packets which carry the DVB service definition. The program_number is the numeric label associated 
with a DVB service. The overall table is contained in one or more sections. It may be segmented to occupy multiple 
sections. 

PAT is always delivered in the Elementary Stream with the PID 0x0000. For video and audio coding in broadcasting 
applications based on the MPEG-2 Transport Stream it is recommended that all sections of PAT are transmitted at least 
once in every 100 ms. 

A DVB network transmits the PAT on every Transport Stream. The PAT contains no descriptors. The program loop 
within PAT contains information about each DVB service within the actual Transport Stream. If the program_number 
0x0000 is announced, the corresponding network_PID field is set to 0x10. 

The program_number of each DVB service available within the Transport Stream is announced. The corresponding 
program_map_PID indicates the PID of the PMT sub_table for the DVB service. A PMT sub_table is carried within an 
Elementary Stream with PID value between 0x0020 ... OxlFFE. PMT sub_tables may be spread over multiple 
Elementary Streams (i.e. PMT sub_table for each DVB service may be delivered on a different Elementary Stream). 
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The PAT table does not contain multiple iterations of the program loop with the same value of the program_number 
field (i.e. each program_number is announced only once). 

4.4.2 Program Map Table (PMT) 

The Program Map Table (PMT) provides mappings between program numbers and the program elements that comprise 
them. A PMT sub_table announces the mapping for a single DVB service. Within a Transport Stream, a PMT sub_table 
is identified by the program_number. A PMT sub_table is also referred to as a "program definition". The PMT is the 
complete collection of all program definitions (i.e. all PMT sub_tables) for a Transport Stream. 

Each PMT sub_table is transmitted in exactly one section, where the section_number field is set to 0. Different PMT 
sub_tables may be delivered on different Elementary Streams. 

Each PMT sub_table is delivered in an Elementary Stream on the PID announced in the PAT. For video and audio 
coding in broadcasting applications based on the MPEG-2 Transport Stream it is recommended that all transmitted 
sections of PMT are transmitted at least once in every 100 ms. The program_number of each DVB program should be 
unique within the network. The PMT sub_table for a particular DVB service is transmitted on the same Transport 
Stream as the referred DVB service. 

Descriptors in the PMT important for use in IPDC in DVB-H Systems are: 

• data_broadcast_id_descriptor. 

For each component containing INT sub_table(s), this descriptor with data_broadcast_id set to OxOOOB 
(IP/MAC Notification Info Structure) is located in the ES_info loop. Each INT sub_table within the 
Elementary Stream is announced. 

• stream_identifier_descriptor. 

For each component carrying IP streams, this descriptor is located in the ES_info loop. The component_tag 
announced within the descriptor is unique for each component within the DVB service. 

4.4.3 Conditional Access Table (CAT) 

Conditional Access Table (CAT) provides information on the CA systems used in the multiplex. 

4.4.4 Transport Stream Description Table (TSDT) 

Transport Stream Description Table (TSDT) provides information about the entire Transport Stream, for example the 
type of target receiver (DVB, ATSC) or the kind of application (e.g. satellite contribution link). All descriptors carried 
within the table apply to the entire Transport Stream. 

4.5 SI Tables 

In addition to the PSI, data is needed to provide identification of DVB services to the user. The coding of this data is 
defined in EN 300 468 [2]. In contrast with the PAT, CAT, and PMT of the PSI, which give information only for the 
multiplex in the actual Transport Stream, the additional SI information can provide information on DVB services 
carried by different multiplexes, and even on other DVB networks. 

The following applies to all SI tables: 

• The section number of the first section of each sub_table is 0x00. 

• The section_number is increment by 1 with each additional section of a sub_table. 

• Time from the transmission of the last byte of a sub_table section to the transmission of the first byte of the 
next section of the same sub table is at least 25 ms. 



• 



Any addition, removal or change in content of any section within a sub_table effects a version number change. 
Two sequential transmissions of a sub_table without a version_number change have the same number of 
sections, and the content and order of sections are identical. 
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4.5.1 Network Information Table (NIT) 



Network Information Table (NIT) conveys information relating to the physical organization of the 
multiplexes/Transport Streams within a given DVB network, and the characteristics of the DVB network itself. DVB 
networks are assigned individual network_id values, which serve as unique identification codes for DVB networks. The 
allocation of these codes may be found in ETR 162 [i.2]. 

It is possible to transmit a NIT for other DVB networks in addition to the actual one. Differentiation between the NIT 
for the actual DVB network (NIT_actual) and the NIT for other DVB networks (NIT_other) is achieved using different 
table_id values. 

The NIT is segmented into network_information_sections. Any sections forming part of an NIT are transmitted in 
Transport Stream packets with a PID value of 0x0010. Any sections of the NIT which describe the actual DVB network 
(that is, the DVB network of which the Transport Stream containing the NIT is part of) have the table_id 0x40, and 
share the same table_id_extension (network_id). The network_id field takes the value assigned to the actual DVB 
network in ETR 162 [i.2]. Any sections of a NIT which refer to a DVB network other than the actual DVB network take 
a table_id value of 0x41 and the network_id takes the value allocated to the other DVB network in ETR 162 [i.2]. 

Each sub_table of the NIT is carried in an Elementary Stream with the PID 0x10. All transmitted sections of a NIT are 
transmitted at least every 10 s. 

The following applies to the transport_stream_loop: 

• Each iteration announces a DVB signal carrying a Transport Stream of the announced DVB network. 

• Each Transport Stream belonging to the announced DVB network is announced. 
Descriptors in the NlT_actual important for use in IPDC in DVB-T/H Systems are: 

• Linkage_descriptor. 

Linkage_type OxOB is used to announce the DVB services containing INT sub_table(s) (i.e. IP/MAC 
Notification Services). If a linkage_descriptor with linkage_type OxOB is available in the NIT_actual, the 
following applies: 

The descriptor is located in the first descriptor loop. 

The list of announced IP/MAC Notification Services is complete, meaning that all IP/MAC Notification 
Services within the actual DVB network are announced. For each IP/MAC Notification Service, all IP 
platforms for which an INT sub_table is available within the DVB service are announced. 

The descriptor may appear more than once in the loop. 

Linkage_type OxOC is used to announce an INT Notification NIT/BAT, i.e. NIT or BAT sub_table containing 
a linkage_descriptor with linkage_type OxOB. If a linkage_descriptor with linkage_type OxOC is available in 
the NIT_actual, the following applies: 

The descriptor is located in the first descriptor loop. 

The list of announced INT Notification NIT/BAT sub_tables is complete, meaning that all INT 
Notification NIT/BAT sub_tables within the DVB network are announced. 

The descriptor may appear more than once in the loop. 

Linkage_type 0x04 is used to announce Transport Streams within the DVB network that contain full network 
SI and bouquet SI. If a linkage_descriptor with linkage_type 0x04 is available in NIT_actual, the following 
applies: 

The NIT and BAT tables within Transport Stream referred contain complete description of the actual 
DVB network. 
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Linkage descriptor_type 0x09 is used to announce System Software Update service and conveys the location 
of the transport stream carrying a system software update service within a network or bouquet respectively. If 
the descriptor is used the following applies: 

The descriptor shall be carried in the first loop of the NIT or in the first loop of a specifically identified 
BAT (called system softwareupdate BAT). 

Linkage descriptor_type OxOA is used to define a pointer to a transport stream carrying a system software 
update BAT or NIT with detailed signalling information about system software update services. 

• Terrestrial_delivery_system_descriptor. 

Each iteration of the second descriptor loop contains exactly one delivery_system_descriptor 
(terrestrial_delivery_system_descriptor in case of IPDC DVB-H Network), announcing the physical 
parameters for the concerned Transport Stream. If the announced Transport Stream is available in multiple 
frequencies, the other_frequency_flag is set to L In which case, either frequency_list_descriptor or 
cell_frequency_link_descriptor is also available. 

• Cell_list_descriptor. 

This descriptor is used to list the cells of a terrestrial DVB network. The list is complete (i.e. all cells and 
subcells are announced). The descriptor may appear more than once in the loop. 

• Network_name_descriptor. 

This descriptor is used to transmit the name of the DVB network. The descriptor is available in the first 
descriptor loop, and should appear exactly once. 

• Cell_frequency_link_descriptor. 

This descriptor announces all frequencies used to transmit the Transport Stream within the DVB network. The 
list is complete. 

• Time_slice_fec_identifier_descriptor. 

This descriptor indicates, whether time-slicing and/or MPE-FEC are used on the Transport Stream. This 
descriptor may occur in the first and in the second descriptor loop. In the first loop, the descriptor applies to all 
Transport Streams of the announced DVB network. In the second loop, the descriptor applies to the particular 
Transport Stream only. Each occurrence overwrites any possible earlier occurrences. Multiple occurrences are 
allowed. 

4.5.2 Bouquet Association Table (BAT) 

Bouquet Association Table (BAT) provides information regarding bouquets. A bouquet is a collection of DVB services, 
which may traverse the boundaries of a DVB network. The BAT is segmented into bouquet_association_sections. Any 
sections forming part of a BAT are transmitted in Transport Stream packets with a PID value of 0x001 1 . The sections of 
a BAT sub_table describing particular bouquet all have the bouquet_id field set to the value assigned to the bouquet 
described in ETR 162 [i.2]. All BAT sections take a table_id value of 0x4A. 



4.5.3 Service Description Table (SDT) 



Service Description Table (SDT) contains data describing the DVB services in the system, e.g. the name of the DVB 
service, the service provider, etc. Each sub_table of the SDT describes DVB services contained within a particular 
Transport Stream. Depending on the table_id, the services are available on the actual Transport Stream or on other 
Transport Streams. 

The SDT is segmented into service_description_sections. Any sections forming part of a SDT are transmitted in 
Transport Stream packets with a PID value of 0x001 1 . Any sections of an SDT which describe the actual Transport 
Stream (that is, the Transport Stream containing the SDT) have the table_id value 0x42 with the same 
transport_stream_id and original_network_id. Any section of an SDT which refer to a Transport Stream other than the 
actual Transport Stream takes a table_id value of 0x46 with the same transport_stream_id and original_network_id. 
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The transmission of the SDT for the actual Transport Stream is mandatory. The SDT hsts all DVB services of the 
referred Transport Stream. 

The descriptors in the SDT for the actual Transport Stream (table_id 0x46) important for use in IPDC in DVB-H 
Systems are: 

• service_descriptor. 

This descriptor contains the basic textual identifications of a DVB service such as service name and provider 
name. The descriptor is allowed only once in each loop. It is mandatory to be transmitted. 

• data_broadcast_descriptor. 

For each Elementary Stream containing MPE section stream, this descriptor with data_broadcast_id set to 
0x0005 (Multiprotocol Encapsulation Info Structure) is available. 

4.5.4 Event Information Table (EIT) 

Event Information Table (EIT) contains data describing events or programmes such as event name, start time, duration, 
etc. The EIT provides information on the events contained within each DVB service in chronological order. 

Four classifications of EIT have been identified, distinguishable by the use of different table_id values: 

• actual Transport Stream, present/following event information, table_id 0x4E; 

• other Transport Stream, present/following event information, table_id 0x4F; 

• actual Transport Stream, event schedule information, table_id 0x50 to Ox5F; 

• other Transport Stream, event schedule information, table_id 0x60 to 0x6F. 

All EIT sub_tables for the actual Transport Stream have the same transport_stream_id and original_network_id values. 

The present/following table contains only information pertaining to the present event and the chronologically following 
event carried by a DVB service on either the actual Transport Stream or another Transport Stream, except in the case of 
a NVOD reference service where it may have more than two event described. The event schedule tables for either the 
actual Transport Stream or other Transport Streams contain a list of events covering a longer schedule. The EIT 
schedule tables are optional. The event information is chronologically ordered. 

The EIT is segmented into event_information_sections. Any sections forming part of an EIT are transmitted in 
Transport Stream packets with a PID value of 0x0012. 

Every SI bit stream carries two sections per DVB service with an EIT present/following with the section_number 0x00 
reserved for the description of the present event and section_number 0x01 for the following event. These constraints do 
not apply in the case of an NVOD reference service which may have more than one event description per section, and 
may have more than two sections in the EIT present/following. 

A DVB network transmits EIT present/following sub_table for each DVB service available within the actual Transport 
Stream at least every 2 s. 



4.5.5 Running Status Table (RST) 



Running Status Table (RST) allows accurate and rapid updating of the timing status of one or more events. This may be 
necessary when an event starts early or late due to scheduling changes and the EIT tables cannot be updated for other 
reasons. The use of a separate table enables fast updating mechanism to be achieved. 

RST shall be segmented into running_status_sections. Any sections forming part of an RST are transmitted in Transport 
Stream packets with a PID value of 0x0013, and the table_id takes the value 0x71. 
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4.5.6 Time and Date Table (TDT) 



The Time and Date Table (TDT) carries the UTC-time and date information. The TDT consists of a single section. This 
TDT section is transmitted in Transport Stream packets with a PID value of 0x0014, and the table_id takes the value 
0x70. 

Transmission of the TDT is mandatory, and it is transmitted at least every 30 s. The encoded time is intended to be valid 
when the section becomes valid as described in figure 3 of TR 101 211 [i.l]. 



4.5.7 Time Offset Table (TOT) 



The Time Offset Table (TOT) carries the UTC-time and date information and local time offset. The TOT consists of a 
single section. This TOT section is transmitted in Transport Stream packets with a PID value of 0x0014, and the 
table_id takes the value 0x73. 

Transmission of the TOT is optional. If transmitted, it is transmitted at least every 30 s. The encoded time is intended to 
be valid when the section becomes valid as described in figure 3 of TR 101 211 [i.l]. 



4.5.8 Stuffing Table (ST) 



The purpose of this clause is to invalidate existing sections at a delivery system boundaries e.g. at a cable head-end. 
When one section of a sub_table is overwritten, then all the sections of that sub_table are overwritten (stuffed) in order 
to retain the integrity of the section_number field. 

A stuffing section may occur wherever a section belonging to an SI table is allowed. STs may be used to replace or 
invalidate either sub_tables or complete SI tables. 



4.5.9 IP/MAC Notification Table (INT) 



The IP/MAC Notification Table (INT) is used to signal the availability and location of IP streams in DVB networks. 
The INT describes the availability and location of IP streams. There may be one or many INTs covering all IP streams 
of a DVB network. The INT is referenced by a data_broadcast_id_descriptor with a data broadcast id of OxOOOB, in the 
ESJnfo loop of the PMT. 

The INT SHALL announce all IP streams of the actual Transport Stream. To support handover the set of announced IP 
streams SHALL also include all IP flows of the actual Transport Stream that are also available on neighbouring 
Transport Streams. To support handover the set of announced IP streams SHALL also include a (sub)set of the IP 
streams of the neighbouring Transport Streams. This (sub)set is composed of those IP streams which transport IP flows 
also available on the actual Transport Stream. 

A neighbouring Transport Stream is a Transport Stream which is transmitted in geographically co-located, adjacent or 
intersecting cells. A neighbouring Transport Stream may belong to the actual network or to another network. 

The descriptors of the INT important for use in IPDC in DVB-H Systems are: 

• target_IP_address_descriptor; 

• target_IP_slash_descriptor; 

• target_IP_source_slash_descriptor. 

These descriptors are used to announce a single or a group of IPv4 destination addresses. These descriptors 
may occur in the target-loop. 

• target_lPv6_address_descriptor; 

• target_IPv6_slash_descriptor; 

• target_IPv6_source_slash_descriptor. 

These descriptors are used to announce a single or a group of IPv6 destination addresses. These descriptors 
may occur in the target-loop. 
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IP/MAC_platfonn_name_descriptor. 



This descriptor is used to announce the name of the IP platform. There may be zero, one or more occurrences 
of this descriptor in the platform-loop. This descriptor may appear more than once, if different 
ISO_639_language_codes are used. 

IP/MAC_platform_provider_name_descriptor. 

This descriptor is used to announce the name of the IP platform provider. There may be zero, one or more 
occurrences of this descriptor in the platform-loop. This descriptor may appear more than once, if different 
ISO_639_language_codes are used. 

IP/MAC_stream_location_descriptor. 

This descriptor is used to announce the location of an IP stream in a DVB network. This descriptor occurs in 
the operational-loop. Multiple occurrences are allowed. 

Time_slice_fec_identifier_descriptor. 

This descriptor indicates, whether time-slicing and/or MPE-FEC are used on a particular Elementary Stream 
carrying MPE sections. This descriptor may occur in the platform descriptor loop and in the operational 
descriptor loop. In the platform loop, the descriptor applies to all Elementary Streams referred to within the 
sub_table. In the target loop, the descriptor applies to all Elementary Streams referred to within the iteration of 
the loop after the appearance of the descriptor. Each occurrence overwrites any possible earlier occurrences. 
Multiple occurrences are allowed. 



4.6 Descriptors 



The complete list of the descriptors, their use in different tables, and descriptor tags may be found in EN 300 468 [2] 
and EN 301 192 [3]. 

4.6.1 network_name_descriptor 

This descriptor is used to transmit the name of a physical network, e.g. "TERACOM". 
This descriptor appears exactly once in the first descriptor loop of any NIT sub_table. 

4.6.2 service_descriptor 

This descriptor provides the names of the DVB service provider and the DVB service itself together with the 
service_type. The names are provided in text form. 

Each iteration of the descriptor loop of any SDT sub_table contains exactly one occurrence of either service_descriptor 
or time_shifted_service_descriptor. 

4.6.3 linkage_descriptor 

This descriptor is used to give a link to another DVB service. 

A Transport Stream carrying an INT sub_table should contain NIT or BAT carrying a linkage_descriptor with a 
linkage_type of OxOB announcing the IP/MAC Notification Service carrying the INT sub_table. 

If a NIT or BAT sub_table contains one or more linkage_descriptors with a linkage_type of OxOB, these linkage 
descriptors announce all IP/MAC Notification Services within the DVB network. 

If a linkage_descriptor with a linkage_type of OxOB is located in the BAT, each NIT_actual of the DVB network should 
contain a linkage_descriptor with a linkage_type of OxOC announcing that BAT. 

A NIT or BAT sub_table containing linkage_descriptors with linkage_type OxOC announce all NIT and BAT sub_tables 
containing linkage_descriptors with linkage_type OxOB within the DVB network. 
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4.6.4 streamJdentifier_descriptor 

This descriptor is used to label component streams with a unique tag value. The tag (component_tag) is unique within 
the DVB service. 

If the descriptor is transmitted, it appears in the ES_info loop of PMT sub_table. 

4.6.5 terrestrial_delivery_system_descriptor 

This descriptor is used to transmit the physical parameters for each DVB signal in the DVB network. 

This descriptor appears exactly once for each transport stream in each NIT sub_table describing the terrestrial DVB 
network. This descriptor shall not appear in a NIT describing a non-terrestrial DVB network. 

4.6.6 data_broadcast_descriptor 

This descriptor identifies the type of data component. 

This descriptor appears in the descriptor loop of the SDT for each DVB service carrying MPE sections. When present, 
the following applies: 

• The descriptor appears for each component carrying MPE sections within the DVB service. 

• The data_broadcast_id field is set to 0x0005, indicating the use of the Multiprotocol Encapsulation Info 
Structure. 

• The selectorjength field is set to 0x02. 

• The component_tag field is set to the value announced within the PMT sub_table of the DVB service for the 
referred component. 

4.6.7 data_broadcastJd_descriptor 

This descriptor identifies the type of data component. 

This descriptor may appear in the ES_info loop of the PMT for each Elementary Stream carrying INT sub_tables. When 
present, the following applies: 

• The data_broadcast_id field is set to OxOOOB. 

4.6.8 transport_stream_descriptor 

This descriptor indicates the compliance of the actual Transport Stream with an MPEG based system. 
This descriptor may appear in the TSDT. If present in a DVB signal, the following applies: 

• The descriptor_length field is set to 0x03, indicating three following bytes. 

• The three bytes contain the value 0x44, 0x56, 0x42 (ASCII: "DVB"), indicating that the Transport Stream is 
compliant with DVB specifications. 

4.6.9 cellJist_descriptor 

This descriptor lists all the cells of the DVB network. The descriptor also lists the locations of the listed cells. 

The descriptor appears in the first descriptor loop of a NIT sub_table describing an IPDC DVB-H Network. 

The cell list is complete. 

Due to the definition regarding the sign of latitudes and longitudes the south-western corner of the rectangle is 
specified. 
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4.6.1 cell_frequencyJink_descriptor 

This descriptor lists all the frequencies used in transmission of a multiplex within the DVB network. It gives a complete 
list of cells and identifies the frequencies that are in use in these cells for the multiplex described. 

The following applies: 

• It appears not more than once in each iteration for which there is a delivery system descriptor. 

• The list of frequencies is complete. 

4.6.1 1 target_IP_address_descriptor 

This descriptor is used to announce IPv4 destination addresses of IP streams within an Elementary Stream. 
If this descriptor is transmitted, it appears in the target-loop of an INT sub_table. 

4.6.12 target_IPv6_address_descriptor 

This descriptor is used to announce IPv6 destination addresses of IP streams within an Elementary Stream. 
If this descriptor is transmitted, it appears in the target-loop of an INT sub_table. 

4.6.13 IP/MAC_platform_name_descriptor 

This descriptor is used to provide the name of the IP platform, e.g. "SONERA GOLD". 
If this descriptor is transmitted, it appears in the platform-loop of an INT sub_table. 

4.6.14 IP/MAC_platform_provider_name_descriptor 

This descriptor is used to provide the name of the IP platform provider, e.g. "SONERA". 
If this descriptor is transmitted, it appears in the platform-loop of an INT sub_table. 

4.6.15 targetJP_slash_descriptor 

This descriptor is used to announce ranges of IPv4 destination addresses of IP streams within an Elementary Stream. 
If this descriptor is transmitted, it appears in the target-loop of an INT sub_table. 

4.6.1 6 target_IP_source_slash_descriptor 

This descriptor is used to announce ranges of IPv4 destination and source addresses of IP streams within an Elementary 
Stream. 

If this descriptor is transmitted, it appears in the target-loop of an INT sub_table. 

4.6.1 7 target_IPv6_slash_descriptor 

This descriptor is used to announce ranges of IPv6 destination addresses of IP streams within an Elementary Stream. 
If this descriptor is transmitted, it appears in the target-loop of an INT sub_table. 

4.6.1 8 target_IPv6_source_slash_descriptor 

This descriptor is used to announce ranges of IPv6 destination and source addresses of IP streams within an Elementary 
Stream. 

If this descriptor is transmitted, it appears in the target-loop of an INT sub_table. 
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4.6.19 IP/MAC_streamJocation_descriptor 

This descriptor is used to announce a location of service components carrying IP streams announced within the 
corresponding target-loop. 

If present, the descriptor appears in the operational-loop of an INT sub_table. 

4.6.20 time_slice_fecJdentifier_descriptor 

This descriptor identifies whether time-slicing and/or MPE-FEC are used on an elementary stream. This descriptor is 
used to announce each time-sliced Elementary Stream. 

When located in the first descriptor loop of NIT, the descriptor applies to all Elementary Streams within all Transport 
Streams within the DVB network. If located in the second descriptor loop of NIT, the descriptor applies to all 
Elementary Streams within the referred Transport Stream, overriding any time-slicing or EEC information from the first 
descriptor loop. 

If located in the platform descriptor loop of an INT, the descriptor applies to all Elementary Streams referenced within 
the table, overriding any time-slicing or EEC information from the NIT. If located in the operational descriptor loop, the 
descriptor applies to all Elementary Streams referenced within the current iteration of the operational descriptor loop 
following the appearance of the descriptor, overriding any time-slicing or EEC information from the platform descriptor 
loop and in the NIT. 

Note that the descriptor applies to Elementary Streams with stream_type 0x90. Other stream_type values may be 
specified later. 

The descriptor may appear more than once, in which case each new occurrence overrides previous occurrence(s). 

4.7 Transmission Parameters Signalling (TPS) 

The Transmission Parameters Signalling (TPS) bits are used to signal parameters related to the transmission scheme, i.e. 
to channel coding and modulation. 

The TPS carriers convey information on: 

constellation including the alpha value of the QAM constellation pattern; 

hierarchy and interleaving information; 

guard interval; 

inner code rates; 

transmission mode; 

frame number in a super-frame; 

cell identification; 

time-slicing indicator; 

MPE-EEC indicator. 

The eight TPS bits s^q to S47 are used to identify the cell to which the DVB signal belongs. These bits contain the 
cell_id. 

Note that cell identification is 16 bits. Therefore when carried in TPS bits, the LSB and MSB of the cell_id are 
interleaved. 
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4.8 Announcing INT 



An INT table may consist of one or more INT sub_tables. INT sub_tables are differentiated by platform_id and 
action_type. The platform_id is used to identify the IP platform, and the action_type indicates the action to be 
performed. Currently the only action type supported is 0x01, which means that location of IP streams in DVB networks 
is announced. 

4.8.1 IP/MAC Notification Service 

Each INT sub_table is carried within a component of a DVB service, also referred to as "IP/MAC Notification Service". 

Within the PMT, each component carrying an INT sub_table is signalled using an IP/MAC Notification Info Structure. 
The IP/MAC Notification Info Structure announces each INT sub_table carried within the announced component. The 
structure is located in the selector field of a data_broadcast_id_descriptor, with the data_broadcast_id field set to 
OxOOOB. 

If multiple INT sub_tables are carried within a single component, they may be announced in one or more IP/MAC 
Notification Info Structures. Each structure is carried within exactly one data_broadcast_id_descriptor, located in the 
ES_info loop of the PMT sub_table announcing the IP/MAC Notification Service. 

4.8.2 IP/MAC Notification NIT/BAT 

Each IP/MAC Notification Service within a DVB network is announced using an IP/MAC Notification Service 
Structure. Each collection of IP/MAC Notification Service Structures is carried in a NIT or BAT sub_table that 
announces each IP/MAC Notification Service within the actual DVB network. The structure is located in a 
linkage_descriptor, with linkage_type field set to value of OxOB. 

If multiple IP/MAC Notification Services are available within the actual DVB network, they may be announced in one 
or more IP/MAC Notification Service Structures. Each such structure is carried within exactly one linkage_descriptor, 
located in the first descriptor loop of a NIT announcing the DVB network carrying the DVB services, or in the first 
descriptor loop of a specifically identified BAT sub_table. Such a NIT/BAT is called 'IP/MAC Notification NIT/BAT'. 

Each IP/MAC Notification NIT/BAT announces each IP/MAC Notification Service within the DVB network. For each 
such DVB service, each IP platform for which INT sub_tables are carried in components of the service, is announced. 

The linkage_descriptor containing an IP/MAC Notification Service Structure may appear more than once within a 
descriptor loop. 

If an IP/MAC Notification BAT is used, the following applies: 

• The BAT sub_table should be announced within the NIT sub_tables describing the actual delivery system. 

• To announce a BAT sub_table, a NIT carries a linkage_descriptor with the linkage_type set to OxOC. 



4.9 Time-slicing and MPE-FEC 



An Elementary Stream carrying MPE sections is time-sliced, i.e. the transmission of sections within the Elementary 
Stream occurs in bursts. Each burst contains at least one MPE section. Sections of other tables (i.e. non MPE) may also 
be carried. 

An Elementary Stream carrying MPE sections may also carry MPE-FEC sections. These sections carry EEC data, 
supporting forward error correction for data packets on MPE section payloads. 

Each MPE section and MPE-FEC section contains real-time parameters, indicating the time to the next burst in the 
Elementary Stream. Empty MPE sections are not allowed. 
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4.10 UNTandSSU 



DVB has defined a System Software Update providing a means of software update for any type of devices from 
multiple manufacturers. The method uses linkage descriptors from either NIT or BAT to the location of the UNT 
(Update Notification Table), or directly to the update stream. 

The UNT (Update Notification Table) has been defined in order to provide a wide range of information and selectors 
for the updates (e.g. scheduling of updates, versioning of updates per manufactures, location of updates, mandatory or 
user agreement required for updating the devices, etc.). 

The complete description of the DVB-SSU mechanism is available in TS 102 006 [7]. 

4.10.1 PSI, SI and Related UNT Signalling 

The PMT references the UNT by including the data_broadcast_id_descriptor (data_broadcast_id = OxOOOA) in the 
ES_info loop, where the update_type in the system_software_update_info is set to 0x2 or 0x3. The 
system_software_update_info OUI, may be either set to the DVB reserved IEEE OUI of 0x00015 A to indicate that 
selection is only possible by analysing the UNT (referenced by this stream in this PMT entry) or the OUI must contain 
another valid IEEE OUI corresponding to a UNT sub-table index. 

Once a candidate UNT has been selected, a search of the table for a sub-table corresponding to the platform's IEEE OUI 
will proceed. If a sub-table is found, a sequential search through each sub-table section's outermost loop, comparing the 
compatibilityDescriptor is performed. 

For each compatibilityDescriptor match, the target descriptors (if any) must also be compared. The target descriptor 
loop targets a specific platform device via one or more of the target descriptors defined in the present document. In the 
case of sequential parsing of the sub-table sections, a match on the compatibility descriptor and the appropriate target 
descriptors ends the search, and no further searching need be performed. 

A successful search will yield, depending upon the action(s) to be performed, a reference to the appropriate data 
carousel via the SSU_location_descriptor's association_tag. This association_tag is used in conjunction with the 
deferred_association_tag_descriptor() in the program descriptor loop of the PMT, or the stream_identifier_descriptor() 
in the ESJnfo loop of the PMT. 

If the update is scheduled, but not yet available, a memorization of start time and location can be performed. 

Complete list of descriptors used in UNT may be found in TS 102 006 [7]. 

Descriptors from the DVB SI range (0x40 to 0x7F) shall have their standard semantics as defined in EN 300 468 [2]. 
Equally MPEG descriptors in the range 0x00 to Ox3F cannot be used in the UNT. 

For the details of each descriptor, please refer to TS 102 006 [7]. 



PSI/SI for IPDC in DVB-H Systems 



The contents of this clause specify the use of PSI and SI tables and related descriptors in IPDC in DVB-H networks. 
The use of PSI/SI tables and/or descriptors not mentioned within this clause is not restricted for any particular network. 
Specifying the use of such tables/descriptors is outside of the scope of the present document. 



5.1 DVB network and IP platform 



If one or more IP streams of an IP platform are carried within a Transport Stream, the Transport Stream SHALL carry 
the INT sub_table describing the IP platform. 

The INT sub_table of a particular IP platform SHALL NOT be carried in multiple Elementary Streams (i.e. only one 
copy allowed) on a particular Transport Stream. 

An Elementary Stream carrying INT sub_table SHOULD NOT carry any other data but INT sub_tables. 

IPDC DVB-H Receiver MAY ignore any other data on an Elementary Stream carrying one or more INT 
sub_tables. 



£75/ 



26 ETSI TS 102 470-1 VI .2.1 (2009-03) 

An Elementary Stream MAY carry multiple INT sub_tables, but it is RECOMMENDED that INT sub_table of each IP 
platform is carried on different Elementary Streams. 

IPDC DVB-H Receiver SHALL support carriage of multiple INT sub_tables on a single Elementary Stream. 

An IP stream MAY be announced on INT sub_tables of two or more IP platforms (i.e. one IP stream MAY belong to 
multiple IP platforms). 

NOTE: This requires IP address space harmonization between the IP platforms. 

IP streams carried within an Elementary Stream SHALL use the same version of IP protocol. I.e. mixing IPv4 and IPv6 
datagrams within a single Elementary Stream is not allowed. 

IPDC DVB-H network MAY use IPv4 and/or IPv6. Within one IP platform, only one IP version SHOULD be 
used. 

Component(s) carrying INT sub_table(s) SHOULD be announced as the first component(s) within the PMT sub_table 
of the DVB service. 

IPDC DVB-H Receiver SHALL NOT assume the INT sub_table is announced as the first component within 
the PMT sub_table of the DVB service. 

All Elementary Streams used to carry IP streams of a particular IP platform SHOULD be announced in a single PMT 
sub_table. 

An INT sub_table of an IP platform SHOULD be announced in the PMT sub_table announcing the Elementary Streams 
carrying IP streams of the IP platform. 

IPDC DVB-H Receiver SHALL support usage of multiple PMT sub_tables on a Transport Stream for a single 
IP platform. 

Within a Transport Stream, each carried INT sub_table SHALL be announced by exactly one IP/MAC Notification Info 
Structure. One IP/MAC Notification Info Structure MAY announce multiple INT sub_tables. The IP/MAC Notification 
Info Structure is carried in data_bradcast_id_descriptor within a PMT sub_table. 

IPDC DVB-H Receiver SHALL NOT assume any particular value for the service_type for a DVB service 
carrying only INT sub_table and/or IP streams. 

Figure 5 illustrates this. Two IP platforms have IP streams available on a Transport Stream. IP platform 1 has twelve IP 
streams, while IP platform 2 has eight IP streams available in the Transport Stream. IP streams are arranged in groups 
of four IP streams, each group carried in different Elementary Stream. Elementary Streams carrying IP streams of IP 
platform 2 are components of DVB service 3. The first component of the DVB service is reserved to carry INT 
sub_table of the IP platform 2. The number of Elementary Streams required for the IP platform 1 is assumed to be too 
big to be announced within a single PMT sub_table (i.e. all Elementary Streams cannot be part of a single DVB 
service). Therefore two separate DVB services are used. The first component of the DVB service 1 is used to carry the 
INT sub_table of IP platform 1 . Rest of the components are reserved for IP streams of the platform. If the DVB services 
would carry any other kind of data streams (e.g. PES streams carrying MPEG-2 coded video or audio), more 
Elementary Streams would be required. 
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IP platform 1 y \ IP platform 2 

Figure 5: A Transport Stream and two IP platforms, approach 1 

Note that this collects Elementary Streams which are used to carry IP streams and the INT sub_table of a given IP 
platform in a single DVB service. Elementary Streams are collected together as components of one (or more) DVB 
service, and such DVB services do not contain any data streams that are not part of the IP platform. This makes it easier 
for an operator of an IPDC DVB-H network to manage the Elementary Streams of an IP platform. 

Figure 6 illustrates a slightly different approach, putting all INT sub_tables in a single DVB service. 



TS 



DVB service 1 



DVB service 2 



DVB service 3 



DVB service 4 




Figure 6: A Transport Stream and two IP platforms, approach 2 

An IP platform MAY have IP streams on multiple Transport Streams within a DVB network. An IP platform MAY 
have IP streams on multiple DVB networks. 

Two Transport Streams carrying IP streams of a particular IP platform, MAY carry the same, partially different, or 
entirely different set of IP flows of the IP platform. 

Two IP flows carried on a single Elementary Stream on a particular Transport Stream, MAY be carried on different 
Elementary Streams on another Transport Streams as well. 



£75/ 



28 ETSI TS 102 470-1 VI .2.1 (2009-03) 

5.2 Multiprotocol Encapsulation (IVIPE) 

To encode an IP flow into a Transport Stream, Multiprotocol Encapsulation (MPE) SHALL be used with 
LLC_SNAP_flag = 0. Stuffing bytes SHALL not be used. 

IPDC DVB-H Receiver SHALL support decoding of IP-on-MPE. 

IPDC DVB-H Receiver SHALL discard MPE sections with LLC_SNAP_flag = 1. 

Each MPE section (datagram_section) SHALL contain exactly one IP datagram. The IP datagram SHALL be complete 
and unbroken, with appropriate source and destination addresses. 

In any Elementary Stream, an IP stream SHALL be carried in a single MPE section stream (i.e. only one MAC address 
used per IP stream). 

On different Elementary Streams or different Transport Streams, different MAC addresses for a particular IP flow MAY 
be used. 

IPDC DVB-H Receiver MAY ignore MAC address when flltering IP streams. 

An Elementary Stream MAY carry multiple IP streams. 

On a particular Elementary Stream, a single MAC address MAY be associated with multiple IP streams (an MPE 
section stream MAY carry multiple IP streams). 

For each Elementary Stream carrying IP stream(s), the SDT_actual SHOULD contain exactly one 
data_broadcast_descriptor with the data_broadcast_id set to 0x05 and the selector_length set to 2, indicating that 
Multiprotocol Encapsulation Info structure is included. The descriptor SHALL be associated with the Elementary 
Stream by means of service_id and component_tag. 

Within a Multiprotocol Encapsulation Info Structure, the alignment_indicator SHALL be set to 0, indicating that an 
alignment of 8 bits is used. Also, the max_sections_per_datagram SHALL be set to 1, indicating that each IP datagram 
is carried within a single MPE section. 

On each MPE section, the MAC address SHOULD NOT be scrambled. 

If the MAC_IP_mapping_flag in the Multiprotocol Encapsulation Info Structure in the data_broadcast_descriptor is set 
to 1, an IP to MAC mapping SHALL be as described in RFC 1 1 12 [4] for IPv4 multicast addresses and RFC 2464 [5] 
for IPv6 multicast addresses. 

The same IP to MAC mapping SHOULD be used for other (non-multicast) addresses, too. This is convenient in that the 
same rule is used for all IP destination addresses, without making difference between unicast, multicast or any other 
kind of address. 

The present document does not cover how the MAC address is formed if MAC_IP_mapping_flag is set to 0. 

Note that the MAC_address_range in Multiprotocol Encapsulation Info Structure limits the number of bytes used to 
carry the MAC address in the MPE section header. 

IPDC DVB-H Receiver MAY ignore the MAC address, and use the IP source and/or destination addresses carried in the 
IP datagram delivered in the payload of an MPE section instead. 

5.3 Void 

5.4 PSI Tables 

5.4.1 Program Association Table (PAT) 

IPDC DVB-H Network SHALL transmit PAT on each Transport Stream of the DVB network. The repetition period of 
PAT is RECOMMENDED to be 100 ms or lower. 
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If an IPDC DVB-H Receiver is receiving an IP stream, the following applies: 

• Receiver SHALL detect changes in the PAT table (version number field). 

• In connection with receiving a burst, Receiver SHALL check for a new version of the PAT during on-time of 
the time-sliced Elementary Stream. Receiver MAY ignore PAT filtering during the off-period of the 
time-sliced Elementary Stream. 



5.4.2 Program Map Table (PMT) 



IPDC DVB-H Network SHALL transmit PMT on each Transport Stream of the DVB network. The repetition period of 
PMT is RECOMMENDED to be 100 ms or lower. 

The PCR_PID field MAY be set to OxlFFF, indicating that no PCR is associated with the program. 

IPDC DVB-H Receiver MAY ignore PCR even if available. 

The following descriptor types are important in IPDC DVB-H System and may appear in a PMT sub_table: 

• stream_identifier_descriptor; 

• data_broadcast_id_descriptor. 

IPDC DVB-H Receiver MAY ignore all other descriptors, when present. 

For each component carrying IP stream(s), the stream_type SHALL be set to value of 0x90. 

The ES_info_loop associated with an Elementary Stream carrying IP stream(s) SHALL contain a 
stream_identifier_descriptor announcing the component_tag of the Elementary Stream. This component_tag SHALL be 
unique within the DVB service. The announced component_tag SHALL have the same value as in the corresponding 
data_broadcast_descriptor in the SDT (if any). 

For each component carrying INT sub_table(s), the stream_type SHOULD be set to value of 0x05. 

Each INT sub_table within an Elementary Stream SHALL be announced using a data_broadcast_id_descriptor in the 
corresponding PMT sub_table. The descriptor SHALL be located in ES_info_loop associated with the component. The 
descriptor SHALL appear exactly once for each INT sub_table carried within the Elementary Stream. In the 
data_broadcast_id_descriptor, the data_broadcast_id SHALL be set to value of OxOOOB, indicating that the descriptor 
contains IP/MAC Notification Info Structure. 

IPDC DVB-H Receiver SHOULD follow changes in PMT sub_table while accessing components of the DVB 
service. I.e. while receiving an INT sub_table or an IP stream carried within the components of a DVB service, 
a Receiver SHOULD also filter for newer versions of the PMT sub_table of that DVB service. 

If an IPDC DVB-H Receiver is receiving an IP stream, the following applies: 

• The Receiver SHALL detect changes in an INT sub_table within the same Transport Stream announcing the 
received IP stream by detecting changes in PMT sub_table announcing the Elementary Stream where INT 
sub_table is carried. 

• In connection with receiving a burst. Receiver SHALL check for a new version of the corresponding PMT 
sub_table during on-time of the time-sliced Elementary Stream. Receiver MAY ignore filtering of the 
particular PMT sub_table during the off -period of the time-sliced Elementary Stream. 

5.4.3 Conditional Access Table (CAT) 

The CAT is providing information about the conditional access method used on this network and where the relevant 
streams can be found. This table is used when the scrambling is performed at the MPEG Transport Stream level. 

NOTE: This table might also be used in order to provide the information of the key management system used at 
the IP level. 
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5.4.4 Transport Stream Description Table (TSDT) 

An IPDC DVB-H Network SHOULD transmit a TSDT. All transmitted sections of the TSDT SHALL be transmitted at 
least every 10 s. 

A TSDT sub_table MAY contain the following descriptor types: 

• transport_stream_descriptor. 

IPDC DVB-H Receiver MAY ignore all other descriptors, when present. 

If TSDT is transmitted, transport_stream_descriptor SHALL be present, the descriptor_length SHALL be set to value of 
0x03, and the following three bytes SHALL contain values 0x44, 0x56, 0x42 (ASCII: "D", "V", "B"). 

IPDC DVB-H Receiver MAY ignore TSDT, when present. 



5.5 



SI Tables 



The following applies to all SI tables: 

• The time between transmitting sequential sections of a sub_table SHOULD NOT exceed 100 ms, and the time 
between the last byte of the preceding section and the first byte of the next section SHALL not be less than 

25 ms. 

• The bandwidth used by an Elementary Stream transmitting sections of any sub_table SHOULD NOT exceed 
1 Mbps calculated over any period of half a second. 

Figure 7 illustrates the requirements for times between sections of a sub_table. The maximum time of 100 ms is 
between sequential sections of a sub_table. The minimum time of 25 ms is between the last section of a sub_table to the 
first section of the next occurrence of the sub_table. The maximum repetition rate of a table defines the maximum time 
within which all sections of every sub_table of the table shall be transmitted once. 

Note that different sub_tables of a particular table may be transmitted simultaneously. 
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Figure 7: Times between sections of sub_tables 



5.5.1 Network Information Table (NIT) 



5.5.1.1 



NIT actual 



An IPDC DVB-H Network SHALL transmit the NIT_actual on each Transport Stream of the DVB network. The 
NIT_actual SHALL contain exactly one delivery system descriptor for each of Transport Streams of the actual delivery 
system and provide valid information about the Transport Stream. 

The following descriptors are important in IPDC in DVB-H System and SHALL appear in a NIT_actual sub_table: 

• network_name_descriptor; 

• linkage_descriptor with a linkage type of OxOB or OxOC; 

• terrestrial_delivery_system_descriptor; 

• cell_list_descriptor; 
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• cell_frequency_link_descriptor. 

The following descriptor MAY appear in a NIT_actual sub_table: 

• time_slice_fec_identifier_descriptor. 

IPDC DVB-H Receiver MAY ignore other descriptors, when present. 

The following applies to each Transport Stream carrying one or more INT sub_tables: 

• The NIT_actual SHALL contain a linkage_descriptor with a linkage_type of OxOB or OxOC. 

• If the NIT_actual carries linkage_descriptor(s) with a linkage_type of OxOB, the following applies: 

The descriptor(s) SHALL announce each DVB service carrying INT sub_table(s) within the actual DVB 
network. 

Each of the descriptor(s) SHALL carry exactly one IP/MAC Notification Service Structure announcing 
one or more IP/MAC Notification Services. 

The list of IP/MAC Notification Services announced SHALL be complete. The list is complete if all INT 
sub_tables within the DVB network are referred to by at least one linkage_descriptor with a linkage_type 
of OxOB. 

The following applies to each Transport Stream not carrying any IP flows: 

• The Transport Stream SHOULD carry a linkage_descriptor with a linkage_type of OxOC within its NIT_actual, 
announcing at least one NIT_actual within the DVB network containing a linkage_descriptor with a 
linkage_type of OxOB. 

The following applies to the network_name_descriptor: 

• The descriptor SHALL appear exactly once in the first descriptor loop. 

• The descriptor SHOULD contain the name of the DVB network (i.e. SHOULD NOT contain an empty string). 
The following applies to the terrestrial_delivery_system_descriptor: 

• The descriptor SHALL appear exactly once in each iteration of the transport_stream_loop (i.e. for each 
announced Transport Stream). 

• If the announced Transport Stream is available in multiple frequencies, the other_frequency_flag SHALL be 

set to "1". 

The following applies to the cell_list_descriptor: 

• The descriptor SHALL be present in the first descriptor loop. 

• The cell and subcell list SHALL be complete. 

• The descriptor MAY appear more than once within the descriptor loop. 
The following applies to the cell_frequency_link_descriptor: 

• This descriptor SHALL appear for the Transport Stream in the transport_stream_loop to list all the frequencies 
where the Transport Stream is available within the DVB network. 

• The list of announced frequencies SHALL be complete. 
The following applies to the time_slice_fec_identifier_descriptor: 

• When located in the first descriptor loop, the descriptor applies to all elementary streams with stream_type 
0x90 within all transport streams announced within the sub-table. 

• When located in the second descriptor loop, the descriptor applies to all elementary streams with stream_type 
0x90 within the specific transport stream. This descriptor overwrites any descriptors in the first descriptor 
loop. 
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IPDC DVB-H Receiver MAY assume the content of NIT_actual being static (i.e. not changing) during the time it is 
attached to a DVB network. Therefore a Receiver may read the content of NIT_actual only when it attaches to the DVB 
network. An IPDC DVB-H Receiver SHOULD read the content of NIT_actual every time it is attaching a DVB 
network (either when powered on, or when changing from a DVB network to another). 

5.5.1.2 NIT_other 

An IPDC DVB-H Network MAY transmit NIT_other on one or more Transport Streams of the DVB network. 
NIT_other has to be valid and only announce an existing network. NIT_other, if transmitted, SHALL contain exactly 
one delivery system descriptor for each of the Transport Streams of the actual delivery system and provide valid 
information about the Transport Stream. 

The following descriptors are important in IPDC in DVB-H System and SHALL appear in any transmitted NIT_other 
sub_table: 

• network_name_descriptor; 

• terrestrial_delivery_system_descriptor; 

• cell_list_descriptor; 

• cell_frequency_link_descriptor. 

The following descriptor MAY appear in a NIT_other sub_table: 

• time_slice_fec_identifier_descriptor. 

IPDC DVB-H Receiver MAY ignore other descriptors, when present. 
The following applies to the network_name_descriptor: 

• The descriptor SHALL appear exactly once in the first descriptor loop. 

• The descriptor SHOULD contain the name of the DVB network (i.e. SHOULD NOT contain an empty string). 
The following applies to the terrestrial_delivery_system_descriptor: 

• The descriptor SHALL appear exactly once in each iteration of the transport_stream_loop (i.e. for each 
announced Transport Stream). 

• If the announced Transport Stream is available in multiple frequencies, the other_frequency_flag SHALL be 

set to "1". 

The following applies to the cell_list_descriptor: 

• The descriptor SHALL be present in the first descriptor loop. 

• The cell and subcell list SHALL be complete. 

• The descriptor MAY appear more than once within the descriptor loop. 
The following applies to the cell_frequency_link_descriptor: 

• This descriptor SHALL appear for the Transport Stream in the transport_stream_loop to list all the frequencies 
where the Transport Stream is available within the DVB network. 

• The list of announced frequencies SHALL be complete. 
The following applies to the time_slice_fec_identifier_descriptor: 



• 



When located in the first descriptor loop, the descriptor applies to all elementary streams with stream_type 
0x90 within all transport streams announced within the sub-table. 

When located in the second descriptor loop, the descriptor applies to all elementary streams with stream_type 
0x90 within the specific transport stream. This descriptor overwrites any descriptors in the first descriptor 
loop. 
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IPDC DVB-H Receiver MAY assume the content of NIT_other being static (i.e. not changing) during the time it is 
attached to a DVB network. Therefore, while attached to a DVB network, a Receiver may read the content of a 
particular NIT_other only once. 

5.5.2 Bouquet Association Table (BAT) 

If linkage_descriptor with linkage type OxOC is located in the NIT_actual of the DVB network, then the IPDC DVB-H 
Network SHALL transmit BAT sub_table (table_id 0x4A) on each of the Transport Streams referred by the 
linkage_descriptor. If NIT_actual does not carry linkage_descriptor with linkage_type OxOC, IPDC in DVB-H Receiver 
MAY ignore BAT, if present. 

If linkage_descriptor with linkage type OxOC is located in the NIT_actual of the DVB network, then following 
descriptor type SHALL appear in the BAT: 

• Linkage_descriptor with linkage_type OxOB. 

If the BAT carries linkage_descriptor(s) with a linkage_type of OxOB, the following applies: 

• The descriptor(s) SHALL announce each DVB service carrying INT sub_table(s) within the actual DVB 
network. 

• Each of the descriptor(s) SHALL carry exactly one IP/MAC Notification Service Structure announcing one or 
more IP/MAC Notification Services. 

• The list of IP/MAC Notification Services announced SHALL be complete. The list is complete if all INT 
sub_tables within the DVB network are referred to by at least one linkage_descriptor with a linkage_type of 
OxOB. 

5.5.3 Service Description Table (SDT) 

An IPDC DVB-H Network SHALL transmit SDT sub_table for the actual Transport Stream (tablejd 0x46). All 
transmitted sections of the SDT for the actual multiplex SHALL be transmitted at least every 2 s. 

The services_loop of the SDT SHALL contain information about all DVB service available within the Transport 
Stream. Each DVB service SHOULD NOT be announced more than once within an SDT sub_table. 

In an IPDC in DVB-H System, the following descriptor types SHALL appear in the SDT of a Transport Stream where 
one or more MPE section streams are available: 

• service_descriptor; 

• data_broadcast_descriptor. 

IPDC DVB-H Receiver MAY ignore other descriptors, when present. 

The following applies to the SDT when announcing a DVB service carrying INT sub_table or IP streams: 

• The EIT_schedule_flag SHOULD be set to value of 0x00, indicating that the EIT schedule information for the 
DVB service is not present in the Transport Stream. IPDC DVB-H Receiver MAY ignore schedule 
information if present. 

• IPDC DVB-H Receiver MAY ignore present/following information if present. 

• The running_status SHOULD be set to value of 0x04, indicating that the DVB service is currently running. 

• The following applies to the service_descriptor: 

The descriptor SHALL be present. 

IPDC DVB-H Receiver SHALL NOT assume any particular value for the service_type. 

The service_provider_name MAY contain the service provider name. IPDC DVB-H Receiver MAY 
ignore service provider name. 
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The service_name MAY contain the DVB service name. IPDC DVB-H Receiver MAY ignore service 
name. 

• The following applies to the data_broadcast_descriptor: 

The descriptor SHALL be present for each component carrying one or more MPE section streams within 
the DVB service. 

It MAY occur more than once. IPDC DVB-H Receiver MAY ignore them all but one, for which the 
following applies: 

■ The data_broadcast_id field SHALL be set to value 0x0005. 

■ The component_tag field SHALL be set to the value of the component announced within the PMT 
sub_table of the DVB service. 

■ The descriptor SHALL contain Multiprotocol Encapsulation Info Structure. For the structure, the 
following applies: 

MAC_address_range SHALL be set to value of 0x01, indicating that only MAC_address_6 in 
the header of MPE sections carried within the referred component contains valid 
MAC-address information. 

MAC_IP_mapping_flag SHOULD be set to '1', indicating that it uses the IP to MAC mapping 
as described in RFC 1 1 12 [4] for IPv4 multicast addresses, and RFC 2464 [5] for IPv6 
multicast addresses. 

Alignment_indicator SHALL be set to '0', indicating that alignment of 8 bits is used. 

Max_sections_per_datagram SHALL be set to value of 0x01, indicating that each IP 
datagram is carried in exactly one MPE section. 

■ IPDC DVB-H Receiver MAY ignore the text description of the data component, if present. 
Note that an IPDC DVB-H Receiver does not use MAC address for filtering MPE section streams. 

An IPDC DVB-H Receiver MAY ignore SDT, when present. 

5.5.4 Event Information Table (EIT) 

IPDC over DVB-H does not require the use of the EIT. Therefore an IPDC DVB-H Receiver MAY ignore the EIT 
when present. 

5.5.5 Running Status Table (RST) 

IPDC over DVB-H does not require the use of the RST. Therefore an IPDC DVB-H Receiver MAY ignore the RST 
when present. 

5.5.6 Time and Date Table (TDT) 

IPDC DVB-H Network SHALL transmit TDT at least once in every 30 s. The TDT SHALL contain the valid 
UTC-time and date information. 

IPDC DVB-H Receiver SHOULD use TDT to synchronize its internal clock. 

5.5.7 Time Offset Table (TOT) 

The network MAY transmit TOT. 

IPDC DVB-H receiver MAY use TOT for getting time zone information and daylight saving time information. 
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5.5.8 Stuffing Table (ST) 

IPDC DVB-H Receiver SHALL ignore ST, when present. 

5.5.9 IP/MAC Notification Table (INT) 

Within the actual transport stream, an IPDC DVB-H Network SHALL transmit an INT sub_table for each IP platform 
delivering IP streams within the Transport Stream. All transmitted sections of the INT SHALL be transmitted at least 
once in every 30 s. 

The processing_order field of an INT sub_table with action_type 0x01 SHALL be set to value of OxFF or 0x00, 
indicating that no ordering is implied. 

The following descriptors MAY appear in platform_descriptor_loop: 

• IP/MAC_platform_name_descriptor. 

Platformjoop MAY contain this descriptor, containing the name of the IP platform in one or more languages. 
The descriptor MAY occur more than once. Each occurrence of the platform_name SHOULD be identical 
with the platform_name announced using the same language code in NIT containing IP/MAC Notification 
Service Structure. 

• time_slice_fec_identifier_descriptor. 

If this descriptor is present in platformjoop, it indicates that all Elementary Streams referred within this INT 
sub_table are time-sliced with parameters announced in this descriptor. 

IPDC DVB-H Receiver MAY ignore all other descriptors in platform-loop. 

Following descriptors MAY appear in target-loop: 

• target_IP_address_descriptor; 

• target_IP_slash_descriptor; 

• target_IP_source_slash_descriptor; 

• target_IPv6_address_descriptor; 

• target_IPv6_slash_descriptor; 

• target_IPv6_source_slash_descriptor. 

Each iteration of 2"'^ loop of INT table SHALL contain at least one of the above listed target-descriptors in target-loop. 

Descriptor_length field of any descriptor in this loop SHALL NOT be set to "0" (i.e. the descriptor SHALL signal at 
least one IP flow). 

An IP flow SHALL NOT be announced in more than one iteration of 2"'^ loop of INT table. 

Following applies to each target_IP_address_descriptor within the 2"'^ loop of INT table: 

• The use of target_IP_slash_descriptor or target_IP_source_slash_descriptor instead is RECOMMENDED. 

• Note that this descriptor can contain maximum of 62 IPv4_addr fields. 

• IPv4_addr_mask field indicates the bits significant in each IP address announced in the following IPv4_addr 
fields within the descriptor. 

• This descriptor refers to every IP flow with any source address and any of the announced destination address. 
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Following applies to each target_IP_slash_descriptor within the 2nd loop of INT table: 

• Note that this descriptor can contain maximum of 5 1 IPv4_addr fields. 

• IPv4_slash_mask indicates the number of significant bits in the corresponding IPv4_addr, starting from the 

msb. 

• This descriptor refers to every IP flow with any source address and any of the announced destination address. 
Following applies to each target_IP_source_slash_descriptor within the 2"'^ loop of INT table: 

• Note that this descriptor can contain maximum of 25 IPv4_addr fields. 

• IPv4_source_slash_mask indicates the number of significant bits in the corresponding IPv4_source_addr, 
starting from the msb. 

• IPv4_dest_slash_mask indicates the number of significant bits in the corresponding IPv4_dest_addr, starting 
from the msb. 

• This descriptor refers to every IP flow with any of the announced source address and any of the announced 
destination address. 

Following applies to each target_IPv6_address_descriptor within the 2"*^ loop of INT table: 

• The use of target_IPv6_slash_de scrip tor or target_IPv6_source_slash_descriptor instead is 
RECOMMENDED. 

• Note that this descriptor can contain maximum of 14 IPv6_addr fields. 

• IPv6_addr_mask field indicates the bits significant in each IPv6 address announced in the following IPv6_addr 
fields within the descriptor. IPv6_addr_mask value ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffOO would indicate that the 

8 Isb of the IPv6_addr value are to be ignored. 

• This descriptor refers to every IP flow with any source address and any of the announced destination address. 
Following applies to each target_IPv6_slash_descriptor within the 2nd loop of INT table: 

• Note that this descriptor can contain maximum of 15 IPv6_addr fields. 

• IPv6_slash_mask indicates the number of significant bits in the corresponding IPv6_addr, starting from the 
msb. IPv6_slash_mask_value 120 would indicate that the 8 Isb of the IPv6_addr value are to be ignored. 

• This descriptor refers to every IP flow with any source address and any of the announced destination address. 
Following applies to each target_IPv6_source_slash_descriptor within the 2nd loop of INT table: 

• Note that this descriptor can contain maximum of seven (7) IPv6_addr fields. 

• IPv6_source_slash_mask indicates the number of significant bits in the corresponding IPv6_source_addr, 
starting from the msb. 

• IPv6_dest_slash_mask indicates the number of significant bits in the corresponding IPv6_dest_addr, starting 
from the msb. 

• This descriptor refers to every IP flow with any of the announced source address and any of the announced 
destination address. 

If the IP/MAC_stream_location_descriptors associated with the first descriptor announce different locations 
than the IP/MAC_stream_location_descriptors associated with the second descriptor (i.e. located in different 
iteration of 2nd loop of INT table), IPDC DVB-H Receiver would need to know which of the locations to use. 
For such cases, following applies: 

If within an INT sub_table an IP flow is announced multiple times using different masks. Receiver 
SHALL use the one with more precise mask (i.e. the mask with more bits set). If several announcements 
are available it is to the implementation to decide which one to use, not to a DVB standard to specify 
this. 
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Following descriptors MAY appear in operational-loop: 

• IP/MAC_stream_location_descriptor. 

Each iteration of 2"'^ loop of INT table SHALL contain at least one IP/MAC_stream_location_descriptor in 
operational-loop, providing the location of IP streams. Given location SHALL NOT occur more than once 
within each iteration of 2"'* loop of INT table. 

• time_slice_fec_identifier_descriptor. 

If this descriptor is present in operationaljoop, it indicates that all Elementary Streams referred within this 
loop after this descriptor are time-sliced with parameters announced in this descriptor. Descriptor applies from 
the next IP/MAC_stream_location_descriptor (if any) to the end of the current iteration of the loop or to the 
next time_slice_fec_identifier_descriptor, whichever comes first. 

The IP/MAC_stream_location_descriptor SHOULD have different content within each iteration of 2"'^ loop of INT 
table (i.e. SHOULD announce different location). 

IPDC DVB-H Receiver MAY ignore all other descriptors in operational-loop. 

The INT SHALL announce all IP streams of the actual Transport Stream. To support handover the set of announced IP 
streams SHALL also include all IP flows of the actual Transport Stream that are also available on neighbouring 
Transport Streams. To support handover the set of announced IP streams SHALL also include a (sub)set of the IP 
streams of the neighbouring Transport Streams. This (sub)set is composed of those IP streams which transport IP flows 
also available on the actual Transport Stream. 

A neighbouring Transport Stream is a Transport Stream which is transmitted in geographically co-located, adjacent or 
intersecting cells. A neighbouring Transport Stream may belong to the actual network or to another network. 

5.6 Transmission Parameter Signalling (TPS) 

Following applies on each cell of an IPDC DVB-H Network: 



• 



A cell SHALL NOT contain multiple Transport Streams where IP streams are carried over DVB-H, except 
when hierarchical modulation is used, in which case there MAY be up to two Transport Streams per cell. 

• In addition to a Transport Stream carrying IP streams over DVB-H, the cell may contain one or more 
Transport Streams where IP streams over DVB-H are not carried. 

• A cell MAY contain multiple subcells. 

5.7 Update Notification Table (UNT) 

IPDC DVB-H Network MAY use UNT table to signal where, when and how System Software Update services can be 
found, as specified in [7]. 

IPDC DVB-H Receiver MAY support System software Update using UNT. 

5.8 Announcing INT 

5.8.1 IP/MAC Notification Service 

An Elementary Stream MAY carry multiple INT sub_tables. 
Following applies to each IP/MAC Notification Info Structure: 

• At least one INT sub_table SHALL be announced. 

• More than one INT sub_tables SHOULD NOT be announced. 
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• If more than one INT sub_tables are announced within a single structure, each SHALL have a different 
platform_id. 

• For each announced platform_id, action_type 0x01 (location of IP/MAC streams in DVB networks) SHOULD 
be announced exactly once. 

• INT_versioning_flag fields SHALL be set to '1', indicating that the INT_version field reflects the changes of 
the announced INT sub_table. 

NOTE: If INT_versioning_flag is set to 1, a Receiver needs to filter only the PMT sub_table to detect changes in 
PMT and INT sub_tables. If the flag is set to 0, the Receiver needs to filter both PMT and INT sub_table, 
therefore requiring one extra filter. 

IP/MAC Notification Service Structure SHALL appear in NIT_actual of each Transport Stream containing one or more 
IP/MAC Notification Services, or in BAT carried on at least one of the Transport Streams of the network. 

5.8.2 IP/MAC Notification NIT 

The following applies to each NIT containing IP/MAC Notification Service Structure: 

• The list of announced IP platforms SHALL be complete, so that each INT sub_table within the entire DVB 
network is referred to by at least one linkage_descriptor containing an IP/MAC Notification Service Structure. 

• A platform_name SHALL be given for each announced IP platform. The platform_name MAY be announced 
just once within each NIT containing IP/MAC Notification Service Structures. 

To get the names of each available IP platform within a DVB network, an IPDC DVB-H Receiver would read the NIT 
containing linkage_descriptors with linkage_type OxOB. Within such NIT, names of each available IP platform are 
announced. 

5.8.3 IP/MAC Notification BAT 

The following applies to each BAT containing IP/MAC Notification Service Structure: 

• A platform_name SHALL be given for each announced IP platform. The platform_name MAY be announced 
just once within each BAT containing IP/MAC Notification Service Structures. 

To get the names of each available IP platform within a DVB network, an IPDC DVB-H Receiver would read the BAT 
containing linkage_descriptors with linkage_type OxOB. Within such BAT, names of each available IP platform are 
announced. 
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